feat: periodic task CRUD (list/delete/pause/resume)#313
Conversation
list_periodic, delete_periodic, and set_periodic_enabled across SQLite/Postgres/Redis. Pause/resume reuses the existing enabled flag (no schema change); get_due_periodic already filters it. Redis gains a periodic:all index for listing.
Native PyQueue bindings over the new storage ops, plus type stubs.
Queue.listPeriodic/deletePeriodic/pausePeriodic/resumePeriodic over the new core ops, with a PeriodicInfo view and an in-memory backend impl. Live-verified by PeriodicTest.
|
Warning Review limit reached
More reviews will be available in 13 minutes and 30 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (8)
📝 WalkthroughWalkthroughPeriodic task list, delete, pause, and resume support was added across core storage backends and exposed through Java and Python APIs. The change also adds periodic task views, backend adapters, and integration tests for the new lifecycle methods. ChangesPeriodic task lifecycle support
Sequence Diagram(s)sequenceDiagram
participant DefaultQueue
participant JniQueueBackend
participant NativeQueue
participant StorageBackend
DefaultQueue->>JniQueueBackend: listPeriodicJson()
JniQueueBackend->>NativeQueue: listPeriodic(handle)
NativeQueue->>StorageBackend: list_periodic()
StorageBackend-->>NativeQueue: periodic rows
NativeQueue-->>JniQueueBackend: JSON array
JniQueueBackend-->>DefaultQueue: JSON array
DefaultQueue->>JniQueueBackend: pausePeriodic(name)
JniQueueBackend->>NativeQueue: setPeriodicEnabled(handle, name, false)
NativeQueue->>StorageBackend: set_periodic_enabled(name, false)
StorageBackend-->>NativeQueue: boolean
NativeQueue-->>JniQueueBackend: boolean
JniQueueBackend-->>DefaultQueue: boolean
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Suggested labels
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@crates/taskito-core/src/storage/redis_backend/periodic.rs`:
- Around line 122-146: `list_periodic` now only reads from the `periodic:all`
index, so older Redis periodic tasks stored under `periodic:*` can be invisible
and leave stale index state. Update the Redis backend in `periodic.rs` to
backfill `periodic:all` from existing `periodic:` task keys (for example during
`list_periodic` or initialization) before building `PeriodicTaskRow`s, and make
sure `delete_periodic` continues to remove both the task key and its index entry
using the same `conn()`, `key()`, and `PeriodicEntry` flow.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 24e2bbb2-2b0f-47cd-a960-eb7f9e4eb9a0
📒 Files selected for processing (19)
crates/taskito-core/src/storage/mod.rscrates/taskito-core/src/storage/postgres/periodic.rscrates/taskito-core/src/storage/redis_backend/periodic.rscrates/taskito-core/src/storage/sqlite/periodic.rscrates/taskito-core/src/storage/sqlite/tests.rscrates/taskito-core/src/storage/traits.rscrates/taskito-core/tests/rust/storage_tests.rscrates/taskito-java/src/convert.rscrates/taskito-java/src/queue/periodic.rscrates/taskito-python/src/py_queue/mod.rssdks/java/src/main/java/org/byteveda/taskito/DefaultQueue.javasdks/java/src/main/java/org/byteveda/taskito/Queue.javasdks/java/src/main/java/org/byteveda/taskito/internal/JniQueueBackend.javasdks/java/src/main/java/org/byteveda/taskito/internal/NativeQueue.javasdks/java/src/main/java/org/byteveda/taskito/model/PeriodicInfo.javasdks/java/src/main/java/org/byteveda/taskito/spi/QueueBackend.javasdks/java/src/test/java/org/byteveda/taskito/PeriodicTest.javasdks/java/test-support/src/main/java/org/byteveda/taskito/test/InMemoryQueueBackend.javasdks/python/taskito/_taskito.pyi
Queue.listPeriodic/deletePeriodic/pausePeriodic/resumePeriodic over the new core ops, with a JsPeriodicTask napi view. Live-verified by the periodic test.
|
Added Node parity (4th commit): |
The periodic:all index only saw tasks registered after this change, hiding pre-existing Redis periodics from list_periodic. Scan the periodic:* keyspace instead (as list_dead/list_workers do) — no secondary index to keep consistent, and tasks from any version are listed.
1 participant
What
P14 periodic management: list / unschedule / pause / resume registered periodic (cron) tasks. Previously only
register_periodicexisted across every SDK.Why minimal core ops (not emulation)
Unlike retry backoff (already in the core engine, #311), periodic management is a genuine gap — the storage trait only had
register_periodic/get_due_periodic/update_periodic_schedule, and a paused task can't be emulated client-side (once registered, the scheduler fires it viaget_due_periodic; stopping it needs a storage op). So this adds the missing ops once, in the core, where every SDK shares them.No schema change: pause/resume reuses the existing
enabledcolumn thatget_due_periodicalready filters on.Layers
taskito-core):list_periodic,delete_periodic,set_periodic_enabledon theStoragetrait + SQLite / Postgres / Redis impls + delegate. Redis gains aperiodic:allindex set (maintained on register/delete, self-healing on list).taskito-python): nativePyQueuebindings (list_periodic/delete_periodic/pause_periodic/resume_periodic) + type stubs.taskito-java+sdks/java): JNI fns →Queue.listPeriodic()(returnsPeriodicInfo) /deletePeriodic/pausePeriodic/resumePeriodic, with an in-memorytest-supportimpl.Verification
test_periodic_crud— green on SQLite + Redis (live, local docker); Postgres compiles + runs in CI.sqlite/tests.rs::test_periodic_pause_resume_and_delete.PeriodicTest(JNI-backed) — list / pause (enabled=false) / resume / delete, all live.cargo checkdefault + postgres + redis;cargo clippyclean; full./gradlew buildgreen; Pythonruff+mypyclean.Notes
enabled; a paused task stays listed but stops firing.@periodic); these native methods give Python the capability — a high-level Python wrapper is a separate, paradigm-specific follow-up.Summary by CodeRabbit
New Features
Bug Fixes
Tests